A large software development environment relies on many developers, or software engineers, developing systems including many software elements. Each software element includes multiple objects, and is spread across many files. Typically, the files include source code, or human readable versions, of computer instructions, and are modifiable by the developers. As is known in the industry, the source code is compiled into object code and eventually into executable code, which is a set of instructions executable by a processor on the target machine for which the system was developed.
Software objects in conventional software systems include or inherit methods and attributes from other objects in the system. Inheritance is usually defined in terms of classes, which inherit other classes (or subclasses), resulting in a complex hierarchical or matrix pattern of inheritance, often called an inheritance hierarchy. Inheritance results in a dependency between the objects or classes, as changes to a particular class triggers a need to propagate the change to classes which inherit, or depend on, the changed class. Such dependencies are typically resolved by a build, which recompiles the affected entities to propagate the changes to dependent classes.
Modern software development methodologies are exhibiting a trend toward so-called middleware based implementations. One popular middleware implementation is CORBA. CORBA is the acronym for Common Object Request Broker Architecture, OMG's open, vendor-independent architecture and infrastructure that computer applications use to work together over networks. CORBA applications are composed of objects, which are individual units of running software that combine functionality and data, and that frequently (but not always) represent something in the real world. In a typical middleware based object oriented architecture, there are many instances of an object of a single type—for example, an e-commerce website would have many shopping cart object instances, all identical in functionality but differing in that each is assigned to a different customer, and contains data representing the merchandise that its particular customer has selected. For other types, there may be fewer instances.
For each object type, such as the shopping cart mentioned above, a developer using middleware such as CORBA, defines an interface in an Interface Description Language (IDL). The interface is a syntax part of a contract that a server object offers to client programs that invoke functionality and access data within that server object. Any client that wants to invoke an operation on the object employs this IDL interface specification (i.e., object specification) to specify the operation the client wants to perform, and to marshal arguments (i.e., parameters or data) that the client sends and receives from the server for access to that object.
The use of a middleware-specific interface, such as a CORBA call, that is separate from the middleware implementation, enabled by the IDL, is one essence of middleware such as CORBA and explains how conventional middleware enables interoperability between applications with all of the above noted transparencies. The interface to each object using a conventional middleware platform is defined very strictly. However, CORBA and other middleware platforms hide the implementation of an object (i.e., its running code and its data) from the rest of the system (that is, middleware encapsulates the implementation) behind a boundary that the client application may not cross. Clients access objects only through their advertised CORBA (or other middleware-specific) interface, invoking only those CORBA (or other middleware) operations that the object exposes through its IDL interface, with only those CORBA (or other middleware) parameters (input and output) that are included in the invocation.